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1.  INTRODUCTION 


Computer  networks  are  becoming  increasingly  widespread;  their  use  already  permeates  our  everyday  life. 
As  a  consequence,  their  correct  functioning  becomes  paramount.  Given  that  computer  networks  are 
extremely  complex  systems,  the  task  of  certifying  that  they  behave  properly  is  nontrivial. 

This  report  presents  an  exercise  in  verifying  that  a  particular  algorithm  to  realize  an  important  function  in 
computer  networks,  namely  connection  establishment ,  does  indeed  behave  properly.  The  methods  discussed 
are  applicable  for  analyzing  a  wide  range  of  other  network  functions  as  well. 

The  remainder  of  this  section  gives  background  material.  Section  1.1  discusses  the  nature  and  need  for 
connection  establishment  in  computer  networks;  Section  1.2  then  presents  a  new  language  suitable  for  the 
specification  of  protocols;  and  Section  1.3  describes  a  system  in  which  properties  of  such  specifications  can  be 
proved. 

Section  2  presents  a  specification  of  a  connection  protocol  currently  in  use,  given  in  the  language 
introduced  earlier.  Section  3  then  discusses  particular  properties  of  this  protocol  and  shows  their  verification. 

1.1  Connection-Establishment  Protocols 

This  section  presents  the  motivation  for  connection-establishment  protocols  in  general  and  for  the  three- 
way  handshake  used  in  the  ARPANET  in  particular.1  Consider  a  distributed  system  with  several 
interconnected  nodes.  The  nodes  are  connected  by  an  unreliable  transmission  medium  in  which  messages 
may  be  lost  or  duplicated,  and  each  node  has  several  processes.  Imagine  now  that  two  processes  wish  to 
communicate;  a  common  method  to  overcome  the  possible  loss  of  data  is  to  attach  a  sequence  number  to  each 
data  packet  that  flows,  in  either  direction,  between  them.  If  the  two  nodes  can  agree  on  a  starting  number  to 
be  used,  again  in  each  direction,  then  they  will  be  able  to  detect  packets  arriving  out  of  order  or  being 
duplicated. 

Suppose  now  that  the  system,  when  it  is  created,  initializes  the  nodes  to  have  agreed-upon  sequence 
numbers,  thus  allowing  the  data  transfer  to  take  place  immediately.  Unfortunately,  such  systems  are 
impractical,  for  a  number  of  reasons. 

First,  since  the  system  is  intended  to  be  distributed,  a  failure  at  one  node  would  require  the  whole  system  to 
be  re-initialized.  Second,  although  there  is  a  potential  for  communication  between  any  two  processes  in  the 
system,  only  a  few  pairs  will  actually  be  engaged  in  data  exchange  at  any  one  time.  Since  the  resources 
needed  to  maintain  communication  between  processes  are  quite  significant,  the  nodes  should  be  able  to  keep 
these  resources  allocated  only  while  the  exchange  is  taking  place,  thus  increasing  their  utilization. 


^Tie  reader  familiar  with  the  three-way  handshake  may  skip  this  section. 
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These  considerations  lead  to  the  notion  of  connections:  When  two  processes  wish  to  communicate,  the 
corresponding  nodes  will  cooperate  among  themselves  to  establish  a  common  frame  of  reference,  e.g., 
sequence  numbers  for  data  flowing  in  each  direction,  for  the  exchange  of  data:  when  the  exchange  is 
complete,  the  connection  is  closed,  freeing  the  resources  for  use  by  other  processes.  The  period  of  time  that  a 
particular  connection  is  open  betw  een  two  processes,  i.e.,  the  period  of  time  a  particular  frame  of  reference  is 
in  effect  is  called  an  incarnation  of  that  connection. 

It  is  clear  that  for  the  exchange  of  data  to  be  successful,  the  two  nodes  must  agree  on  the  state  of  the 
connection.  A  further  problem  is  introduced  by  the  fact  that  the  transmission  medium  may  delay  or  duplicate 
packets  that  flow  between  the  two  nodes.  Since  connections  can  open  and  close,  it  is  possible  for  packets  from 
old  incarnations  to  be  in  the  medium;  when  they  are  present,  they  should  not  be  mistaken  for  packets 
belonging  to  a  newly  opened  connection. 

Since  packets  may  be  lost,  a  positive-acknowledgment  retransmission-on-timeout  scheme  is  used.  In  other 
words,  the  sender  keeps  a  copy  of  each  packet  sent  until  the  receiver  acknowledges  that  the  packet  has  been 
received.  If  no  acknowledgment  arrives  after  some  predefined  amount  of  time,  it  is  assumed  that  the  packet 
or  its  acknowledgment  was  lost  and  it  is  retransmitted.  Acknowledgments  themselves  are  not  acknowledged. 

It  is  important  to  note  that  if  there  is  a  positive  probability  (no  matter  how  small)  that  a  packet  is  lost  then 
it  is  actually  impossible  to  completely  separate  the  connection-establishment  from  the  data  transfer  itself.  To 
see  why.  consider  the  last  (synchronization)  packet  exchanged  during  the  connection  establishment;  each 
node  will  consider  the  connection  to  be  open  upon  sending  and  receiving  this  packet.  It  is  clear  that  the  node 
receiving  this  packet  can  be  sure  that  the  other  node  has  a  compatible  view  of  the  connection.  The  sender, 
however,  cannot  be  so  sure,  given  the  possibility  that  this  last  packet  may  be  lost;  only  when  the  first  data 
packet  arrives  (in  the  reverse  direction)  will  it  be  sure  that  the  other  node  actually  received  it.  Therefore,  the 
sender  node  must  maintain  both  the  data  exchange  and  the  connection-establishment  information  for  that 
period  of  time.  An  equivalent  problem  is  discussed  in  [2], 

In  many  systems,  connections  are  opened  and  closed  quite  frequently.  Since  the  medium  may  duplicate 
packets,  it  is  possible  for  a  connection-request  packet  from  a  previous  incarnation  to  appear  at  one  node  at 
such  a  time  as  to  be  mistaken  for  a  current  one,  thereby  initiating  a  connection  with  the  wrong  frame  of 
reference  (see  [15]). 

A  problem  still  remains  as  to  how  to  identify  packets  from  previous  incarnations  as  being  old.  The 
sequence  numbers  chosen  to  establish  the  frame  of  reference  of  a  new  connection  must  prevent  that. 
Sunshine,  in  [15],  discusses  this  issue  in  more  detail. 

A  protocol  has  been  proposed  to  handle  the  connection-establishment  problems  discussed  so  far.  It  is  called 
the  three-way  handshake  [19. 15].  The  particular  version  used  here  is  taken  from  TCP  [12],  the  second- 
generation  transport-level  protocol  being  used  in  the  A  R  PA  internet  system. 
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This  protocol  derives  its  name  from  the  sequence  of  steps  a  node  goes  through  in  order  to  establish  a 
connection.  Suppose  that  node  A  wishes  to  communicate  with  node  B  and  that  node  A  takes  the  initiative. 
The  two  nodes  then  go  through  the  following  steps: 

1.  Node  A  sends  node  B  a  connection  request,  called  SYN  (for  SYNchronize). 

2.  Node  B  receives  the  SYN  packet  and  responds  with  a  SYN  of  its  own  together  with  an 
acknowledgment,  together  called  SYNACK  (for  SYNchronize  and  ACKnowledge). 

3.  Node  A  receives  the  SYNACK  packet,  verifies  that  the  ACK  portion  does  indeed  acknowledge  its 
own  previous  SYN,  and  sends  an  ACK  packet  acknowledging  node  B’s  SYN.  At  this  point,  node 
A  considers  the  connection  to  be  opened. 

4.  Node  B  receives  the  ACK  packet,  verifies  that  it  does  acknowledge  its  own  previous  SYN,  and 
then  considers  the  connection  to  be  opened. 

There  are  two  basic  modes  for  opening  a  connection:  an  active  mode,  in  which  the  issuing  node  takes  the 
initiative;  and  a  passive  mode,  in  which  the  issuing  node  merely  listens  for  incoming  connection  requests,  and 
accepts  the  first  to  come  in.  The  basic  protocol  described  above  can  be  modified  to  handle  the  case  when  both 
nodes  do  an  active  open  simultaneously. 

If  at  any  point  an  incorrect  packet  arrives,  then  a  RST  (reset)  packet  is  sent  back  to  abort  the  connection¬ 
opening  procedure. 

Figure  1-1  contains  a  state-transition  diagram  taken  from  [12].  It  does  not  show  transitions  caused  by  RST 
or  incorrect  packets. 

1 .2  Overview  of  SPEX 

We  present  here  an  overview  of  a  language,  called  SPEX,  to  be  used  for  the  specification  of  a  distributed 
system  in  general  and  computer  networks  in  particular.  This  language  will  be  used  later  to  describe  the  three- 
way  handshake  protocol.  As  will  be  evident  from  the  details  given  below,  the  underlying  model  in  SPEX  is 
that  of  a  nondeterministic  state-transition  system,  with  some  specialized  features  to  facilitate  protocol 
specification.  SPEX  is  discussed  at  greater  length  in  [13]. 

A  system  is  regarded  as  consisting  of  a  set  of  interconnected  Nodes.  In  the  case  of  the  example  presented 
here,  a  Node  can  be  a  Station  or  a  Medium.  The  pattern  of  interactions  of  the  nodes  constitutes  the  layer's 
definition.  A  particular  pattern  of  behavior  characterizes  a  node's  type.  A  system  may  in  general  be  composed 
of  several  distinct  types  of  nodes,  each  with  its  own  behavior,  and  may  have  several  instances  of  each  type  of 
node  as  well. 

Thus,  in  order  to  completely  characterize  a  system,  it  is  necessary  to  describe  the  behavior  of  each  type  of 
node  (given  in  the  Node  Behavior  part  of  the  specification),  the  set  of  instances  of  each  node  type  and  the  way 
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Figure  1*1:  Three-way  handshake  state-transition  diagram 


the  instances  are  interconnected  (given  in  the  Topology  pan),  and  the  desired  properties  of  the  interactions 
between  the  instances  (given  in  the  Properties  part).  In  addition,  the  specification  of  any  data  types  used  in 
specifying  a  node's  behavior  must  be  included. 

A  node  is  some  entity  that  has  some  internal  State  Variables  and  some  externally  visible  Interface 
Variables ;  these  variables  may  be  of  arbitrarily  complex  data  types  (which  may  be  defined  using  algebraic 
data  type  specification  methods  [9.  7,  8,  5].).  A  node  reacts  to  a  set  of  specified  Events.  When  one  such  event 
occurs,  some  state  variables  and  some  interface  variables  may  have  their  values  changed. 

State  variables  can  be  accessed  only  locally  at  each  node.  Interface  variables,  on  the  other  hand,  can  be 
accessed  from  the  outside-this  is  how  a  node  communicates  with  the  outside  world,  i.e..  other  nodes  in  the 
same  system  or  other  systems  using  the  system  in  which  the  node  is  defined.  Accordingly,  the  interface 
variables  at  each  node  are  divided  into  two  kinds:  those  that  are  exported  to  other  systems,  and  those  that  are 
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connected  to  other  nodes  in  the  same  system.  In  addition,  each  interface  variable  may  have  a  direction  of  data 
flow  associated  with  it,  meaning  that  data  in  that  variable  flows  into  or  out  of  a  node;  if  no  direction  is 
specified,  data  in  that  variable  flows  in  both  directions. 

The  actual  behavior  of  a  node  is  given  by  describing  how  a  node  reacts  to  the  occurrence  of  certain 
specified  events.  Each  event  known  at  a  node  has  a  precondition  associated  with  it;  this  precondition  is  a 
predicate  involving  state  and  interface  variables  at  that  node.  As  long  as  a  precondition  is  true ,  its  associated 
event  is  said  to  be  enabled;  enabled  events  may  fire  at  any  time. 

The  node's  behavior  is  given  in  terms  of  the  new  values  of  all  its  variables  when  each  of  the  possible  events 
occurs.  All  changes  for  an  event  are  considered  to  happen  simultaneously,  i.e.,  the  events  are  considered 
atomic.  This  means  that  if  any  variable  X  is  used  to  compute  the  new  value  of  some  variable,  the  value  used 
in  the  computation  is  the  value  X  had  before  the  event  happened.  For  brevity’s  sake,  if  a  variable  is  not 
mentioned  on  the  left-hand  side  of  any  event-effects  statement,  then  its  value  is  not  changed  by  the 
occurrence  of  that  event. 

Since  state  variables  are  not  visible  externally,  they  can  be  regarded  as  history  variables  [11  j  which 
accumulate  information  about  the  computation. 

Since  interface  variables  are  externally  visible,  it  is  possible  for  an  event  el  at  some  node  N1  to  change  the 
value  of  some  interface  variable  at  another  node,  say  N2.  In  fact,  el  may  actually  enable  some  event  at  N2; 
this  is  effectively  how  nodes  exchange  data  and  synchronize  their  activity. 

The  last  item  necessary  to  completely  describe  a  node's  behavior  is  its  Initial  Slate ,  specifying  the  values  of 
any  variables  at  system-creation  time.  The  most  general  way  to  specify  the  initial  state  is  to  give  predicates 
which  must  be  true  in  the  initial  state;  it  may  not  be  necessary  or  even  possible  to  give  actual  values  to  the 
variables. 

All  of  the  above  must  be  specified  for  each  node  type  that  exists  in  the  system. 

The  overall  system  behavior  specified  is  defined  as  the  set  of  all  valid  sequences  of  events.  A  valid  sequence 
is  formed  by  surfing  from  an  initial  state  (i.e.,  a  state  satisfying  the  initial  sute  predicates)  and  successively 
firing  enabled  events;  it  may  be  of  infinite  length.  If  it  is  of  finite  length,  then  the  final  sute  arrived  at  by 
executing  the  sequence  has  no  enabled  events. 

Once  all  node  types  have  been  specified,  it  is  necessary  to  describe  how  the  several  nodes  are  connected. 
This  is  achieved  by  allowing  interface  variables  at  each  node  to  be  connected  to  interface  variables  at  other 
nodes;  the  intended  semantics  is  that  these  are  in  fact  shared  variables  between  the  corresponding  nodes. 

The  Topology  part  then  specifies  how  the  interface  variables  of  each  nrde  in  the  system  (i.e.,  each  insunce 
of  each  type  of  node)  are  connected  to  interface  variables  of  the  other  nodes. 
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The  Properties  section  states  two  kinds  of  properties  of  the  protocol.  Assumed  and  Asserted  properties. 
Asserted  properties  are  those  that  must  be  proved  true  by  the  specifier  and  serve  as  an  additional  check  of  the 
accuracy  of  the  specification.  In  other  words,  proving  these  properties  increases  the  confidence  of  the  specifier 
that  the  specification  corresponds  to  her/his  intuitive  understanding  of  the  system. 

Assumed  properties  are  used  to  define  certain  operations  in  a  noncomputational  fashion  by  giving  input- 
output  relationships  between  arguments  and  returned  values. 

SPEXifications2  can  be  conveniently  translated  into  algebraic  style  data  type  specifications  of  the  kind  that 
are  supported  by  the  Affirm  system  (see  Section  1.3).  This  capability  can  be  exploited  to  prove  properties  of 
the  protocol  using  analysis  methods  from  the  abstract  data  type  specification  domain  or  to  perform  a  limited 
form  of  symbolic  execution  of  the  specification,  w  hich  helps  in  determining  the  accuracy  of  the  specification.3 
This  translation  is  dicussed  in  detail  in  [13j. 

An  overview  of  algebraic  specification  of  data  types  and  of  Affirm  is  given  in  the  next  section. 

1 .3  Overview  of  Algebraic  Specification  of  Data  Types  and  of  Affirm 

The  material  presented  in  this  section  has  been  abridged  from  [4.  17], 

Affirm  [10]  is  an  experimental  system  for  the  algebraic  specification  of  and  the  verification  of  properties  of 
user-defined  abstract  data  types.  The  heart  of  the  system  is  a  natural  deduction  theorem  prover  for  the 
interactive  proof  of  these  properties,  which  are  stated  in  the  predicate  calculus  extended  with  data  types. 
Programs,  written  in  a  variant  of  Pascal  extended  with  user-defined  abstract  data  types,  may  be  verified  using 
the  inductive  assertion  method  [3].  Additional  features  include  tools  for  the  analysis  of  algebraic 
specifications,  a  library  of  useful  data  types,  and  user  interface  facilities.  Experience  with  Affirm  includes 
extensive  experimentation  w  ith  data  type  specifications,  verification  of  small  programs,  the  specification  and 
partial  proof  of  a  large  file-updating  module,  and  the  proof  of  high-level  properties  of  security  kernels. 

The  specification  and  theorem-proving  portions  of  Affirm  are  relevant  to  the  current  discussion. 

Like  other  specification  and  verification  systems.  Affirm  follows  its  own  particular  theoretical  and 
programming  paradigm--abstract  data  types  specified  algebraically  and  properties  verified  by  rewriting  rule 
techniques.  A  brief  description  of  the  algebraic  style  of  data  type  specifications  and  of  the  theorem-proving 
portions  of  Affirm  follows. 


"  "SPEXificauon"  will  be  used  10  mean  SPEX  specification 

3I  e  whether  the  specification  captures  the  designer's  intuitive  understanding  of  the  system 
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Following  the  algebraic  style  of  data  type  specifications  [9.  7,  8,  6,  5],  a  data  type  is  specified  by  first 
defining  three  sets  of  functions: 

1.  Constructors.  These  functions  create  values  of  the  type.  Their  range  is  the  data  type  being 
specified.  All  values  of  the  type  can  be  described  in  terms  of  some  functional  composition  of 
these  functions. 

2.  Extenders  (or  Modifiers).  Ihese  functions  also  have  the  data  type  being  specified  as  their  range, 
but  in  contrast  to  the  constructors,  they  are  not  needed  to  express  values  of  the  data  type-they  are 
derived  operators.  These  functions  can  be  defined  in  terms  of  the  constructors. 

5.  Selectors.  These  functions  yield  values  of  types  other  than  the  one  being  specified.  The  general 
term  for  these  functions  is  selector,  but  functions  yielding  values  of  type  Boolean  are  often  termed 
predicates.  These  functions  are  defined  in  terms  of  the  parameters  of  the  constructors 


For  example,  the  constructors  of  a  queue  are  NewQueue  (the  empty  queue)  and  Add  (appends  an  element 
to  a  queue).  Example  extender  functions  are  Remove  (deletes  the  first  element  from  a  queue)  and  Append 
(concatenates  two  queues).  Observe  that  these  extender  functions  can  be  defined  in  terms  of  the  constructors 
NewQueue  and  Add.  Example  selector  functions  are  Front,  tf  Elements  and  in  (a  predicate).  These  are 
definable  in  terms  of  the  parameters  to  Add. 

The  effect  of  such  a  specification  is  to  view  values  of  the  type  in  terms  of  the  constructors  which  can  build 
them.  Hence,  all  selectors  and  extenders  are  defined  in  terms  of  these  constructors.  For  example,  the  queue 
of  integers 

<1 , 2,  3> 

is  represented  (in  infix  form)  as 

((NewOueueOf Integer  Add  1)  Add  2)  Add  3 

The  first  part  of  a  specification  gives  the  signature  of  all  operations,  i.e..  their  domains  and  their  ranges. 
Figure  1-2  shows  an  example  for  the  type  QueueOflnteger. 


declare  q.q'QueueOf  Integer; 
declare  ilnteger; 

interface  NewQueueOf Integer,  q  Add  i :  QueueOflnteger; 
interface  Remove(q),  Append(q.q') :  QueueOflnteger; 
interface  it Elements(q),  Front(q) :  Integer; 
interface  i  in  q:  Boolean; 


Figure  1-2:  Signature  of  type  QueueOflnteger 


The  second  pan  of  a  data  type  specification  provides  semantics  for  the  operations  whose  domain  and  range 
information  was  given  in  the  first  pan.  Extenders  and  selectors  are  defined  by  equational  axioms  of  the  form 
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Ihs  =  =  rhs  relating  how  each  function  behaves  when  applied  to  each  of  the  constructors.  Constructor 
functions  are  treated  as  primitive,  unspecified  operations. 

Examples  of  axioms  taken  from  a  specification  of  the  type  QueueOflmeger  are  given  in  Figure  1-3. 


axioms 

Remove(NewOueueCH  Integer)  =  =  NewQueueOtlnteger. 

Remove(q  Add  i)  =  =  if  q  =  NewQueueOtlnteger 
then  q 

else  Remove(q)  Add  I, 

#Elements(NewQueueOf  Integer)  =  »  0, 

#Elements(q  Add  i)  =  =  Elements(q)  +  1; 

Append(q,  NewQueueOtlnteger)  =  =  q, 

Append(q1.  q2  Add  i)  =  =  Append(q1,  q2)  Add  i. 

Figure  1-3:  Some  axioms  for  type  QueueOflmeger 


Data  types  in  general  have  properties  that  the  specifier  may  wish  to  prove.  For  example,  "the  number  of 
elements  in  the  concatenation  of  two  queues  is  the  sum  of  the  number  of  elements  in  each  queue."  Formally, 
this  property  is  stated  as 

#Elements(Append(q,q’))  =  #Elements(q)  +  #Elements(q’) 


Properties  of  a  data  type  are  proved  using  a  method  called  structural  induction  [14,  7]  which  is  based  on  the 
notion  that  all  values  of  the  data  type  can  be  produced  by  repeated  applications  of  the  constructor  functions. 
To  prove  a  property  P  of  all  element  of  a  data  type,  it  suffices  to  show  that 

1.  It  is  true  for  the  "base"  cases-the  constructors  that  produce  values  of  the  type  without  taking 
values  of  the  type  as  arguments  (e.g.,  P(NewQueue)). 

2.  Assuming  P  is  true  for  some  value  q,  then  it  is  also  true  for  all  values  obtained  by  applying 
constructors  to  q  ( e.g.,  for  all  q.i  P(q)  implies  P(q  Add ;)). 

There  is  much  more  to  specifying  a  data  type  specification  than  just  giving  a  set  of  axioms.  A  good  data 
type  specification  should  provide  the  desired  set  of  operations.  These  operations  should  have  the  expected 
(intuitive)  properties.  The  axioms  should  also  facilitate  simple  proofs.  In  other  words,  the  type  has  an 
associated  theory  that  expresses  properties  derived  from  the  axioms.  (Building  these  theories  is  a 
mathematical  art.)  The  main  method  of  proof  of  such  properties  is  induction,  for  which  the  schema  part  of  a 
type  provides  the  proof  structure. 


Affirm  is  not  exactly  a  proof  checker,  nor  is  it  a  proof  finder.  The  responsibility  for  finding  and  executing 
a  proof  strategy  rests  solelv  with  the  user.  At  each  proof  step,  modifications  are  made  to  a  system-maintained 
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proof  structure.  Then  the  rewriting  rules  of  the  data  types  of  the  program,  together  with  the  rules  of 
propositional  logic,  are  applied  to  simplify  the  proposition  currently  being  worked  upon.  In  general,  the  user 
is  attempting  to  reduce  a  formula  to  a  set  of  subgoals  so  simple  that  their  proofs  are  immediate,  i.e.,  can  be 
obtained  by  the  system  without  further  direction.  Some  example  commands  for  carrying  out  proofs  and  their 
effects  are: 

try  proposition  Set  up  proposition  as  the  current  goal. 
employ  Induction(v) 

Induction  is  a  user-defined  schema  for  the  type  of  induction  desired  and  v  is  the  variable  to 
be  induced  upon.  The  proof  structure  is  modified  to  show  the  various  cases  of  the 
induction. 

apply  proposition  Use  proposition  as  a  lemma  in  the  proof  (proposition  must  be  proved  or  assumed 
separately).  A  separate  put  command  instantiates  the  variables  in  the  lemma  to  the  proper 
values  in  the  current  goal. 

suppose  proposition 

Break  the  current  goal  into  two  subgoals,  one  with  the  additional  hypothesis  proposition 
and  the  other  with  ~ proposition . 

split  Break  up  the  proposition  at  a  designated  spot  into  subgoals,  e.g.,  the  proposition  H  imp  (C l 

and  C  J  can  be  split  into  the  two  propositions  H  imp  C;  and  (H  and  C{)  imp  Cr 

replace  Replace  subexpressions  with  other  subexpressions  according  to  designated  equalities  in  the 

current  proposition. 

invoke  defn  Invoke  a  definition  defn  that  the  user  has  made  at  some  time. 

The  user  can  explore  various  av  enues  of  proof  until  the  proof  is  complete  or  until  the  conjecture  is  found  to 
be  unprovable,  at  which  point  the  proof  of  the  corrected  conjecture  must  be  restarted  or  the  bad  proof  steps 
corrected. 

Each  theorem  or  intermediate  proposition  in  Affirm  is  represented  by  a  named  node  in  a  directed  acyclic 
graph  called  the  proof  forest.  The  proof  of  a  theorem  comprises  a  tree,  whose  named  arcs  represent  Affirm 
commands  and  thus  deductive  steps.  Affirm  checks  for  circularity  within  the  current  tree. 

An  example  of  an  Affirm  proof  is  discussed  in  Section  3. 


1 .4  Relation  to  Other  Work 

There  is  a  large  body  of  work  regarding  techniques  for  specifying  protocols.  These  include  Petri  nets  (and 
related  graph  models),  formal  languages,  sequencing  expressions,  and  (parallel)  programming  languages. 
Much  of  this  work  is  limited  in  expressive  power,  in  the  sense  that  specifications  grow  unproportionally  large 
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as  the  complexity  of  the  protocol  being  specified  increases.  Many  also  suffer  from  lack  of  a  solid  theory  or  of 
automated  tools  for  verification.  Sunshine  [16]  provides  a  survey  of  this  work. 

Although  the  underlying  model  of  SPEX  is  not  new,  it  is  believed  to  be  the  first  language  allowing  the 
formal  specification  of  nondeterministic  state  transition  systems  in  a  modular,  hierarchical  fashion,  and  for 
which  semi-automated  verification  tools  exist.  An  important  advantage  of  the  modularization  and  the 
symbolic  nature  of  the  specification  is  that  there  is  no  combinatorial  explosion  when  analyzing  more  complex 
protocols.  Schwabe  [13]  provides  an  example  in  which  a  complex  protocol,  involving  an  arbitrary  number  of 
nodes,  is  specified  and  verified,  but  where  the  complexity  of  the  proof  is  independent  of  the  number  of  nodes. 


2.  SPECIFICATION  OF  THE  THREE-WAY 
HANDSHAKE  IN  SPEX 

This  section  examines  a  SPEXification  of  the  three-way  handshake  protocol  described  informally  in 
Section  1.1.  Appendix  I  contains  the  actual  text  of  the  SPEXification. 

First  the  state  variables,  interfaces,  initial  state,  and  events  for  one  station  are  given;  the  main  portion  of  the 
specification  shows  the  behavior  of  the  station  for  each  event.  A  small  specification  for  the  medium  is  also 
given,  stating  that  the  medium  is  essentially  a  queue  with  an  added  LoseMessage  event.  In  the  sequel,  a  brief 
explanation  of  the  SPEX  ification  is  given. 

The  three-way  handshake  protocol  involves  two  nodes  with  identical  behavior.  The  corresponding  node 
type  is  Station. 

Each  station  needs  the  following  state  variables: 

ISS  is  some  constant  to  be  used  as  Initial  Send  Sequence  number. 

Incarnation#  In 

is  an  incarnation  identification  for  the  packets  coming  in  from  the  other  node. 

Incarnation#  Out 

is  an  incarnation  identification  for  the  packets  leaving  this  node. 

OldUnack 

is  the  sequence  number  of  the  oldest  sent  packet  which  has  not  yet  been  acknowledged. 

Seq#ToSend 

is  the  sequence  number  that  should  be  attached  to  the  next  data  packet  to  be  sent 
Seq#ToReceive 

is  the  expected  sequence  number  of  the  next  packet  coming  in. 

Timeout  Buffer 

is  a  queue  of  packets  containing  copies  of  packets  which  have  been  sent  but  not  yet  acknowledged.4 

The  exported  interface  to  using  systems  contains  two  variables: 

Command 

is  a  command  buffer  through  which  the  user  indicates  what  type  of  open  request  is  desired. 


A 

Stnctly  speaking,  TimeoulBuffer  does  not  have  to  be  a  queue,  but  just  a  collection,  of  packets.  Modeling  it  as  a  queue  results  in 
simpler  axioms  in  this  situation. 
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StaieOf 

is  a  variable  that  remembers  the  state  of  the  station,  i.e.,  somehow  remembers  the  recent  history  of 
messages  that  have  been  exchanged.  Its  value  can  be  one  of  {Closed,  Listen,  SynSent,  SynReceived, 
Established}. 

Each  station  has  two  interface  variables  which  are  internal  to  the  system,  namely: 

InPort 

is  a  queue  of  incoming  packets,  with  possible  loss. 

OutPort 

is  a  queue  of  outgoing  packets,  with  possible  loss. 

The  initial  state  of  each  station  requires  that  the  State  of  the  station  be  Closed ,  the  Timeout  Buffer  be  empty 
and  the  sequence  numbers  and  incarnation  number  of  incoming  packets  be  zero.5 

The  events  to  which  a  station  can  react  are: 

ActiveOpen 

which  is  caused  when  the  user  issues  an  active  open  command.  This  means  that  a  connection  request 
will  be  sent  to  the  other  party. 

PassiveOpen 

which  is  caused  when  the  user  issues  a  passive  open  command.  This  means  that  the  station  will  listen 
for  incoming  connection  requests  and  accept  the  first  one  that  comes. 

Timeout 

which  is  caused  when  a  timeout  occurs,  i.e.,  when  a  certain  amount  of  time  has  elapsed  without  a  packet 
being  acknowledged. 

ReceiveRst 

which  is  caused  when  a  packet  arrives  whose  control  field  is  rst  (reset).  This  is  a  control  packet  used  to 
indicate  the  discovery  of  an  anomalous  situation. 

ReceiveAck 

which  is  caused  when  an  acknowledgment  packet  arrives. 

ReceiveSyn 

which  is  caused  when  a  packet  arrives  whose  control  field  is  syn  (synchronize).  This  is  a  connection 
request. 

ReceiveSynAck 

which  is  caused  when  a  packet  which  is  both  an  acknowledgment  and  a  connection  request  arrives. 


5 


Zero  is  used  as  an  arbitrary  initial  value. 
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The  node  type  representing  the  medium  has  only  an  interface  variable.  Buffer ,  which  is  a  queue  of  packets. 
There  is  only  one  event  that  can  happen,  LoseMessage,  which  models  the  medium  being  faulty.  Note  that  the 
transmit  operation  of  the  medium  is  modeled  as  an  Add  to  the  queue,  and  the  receive  operation  is  modeled  as 
a  Remove  from  the  queue,  with  the  packet  delivered  obtained  by  Front  of  the  queue  (before  the  Remove). 

The  definition  of  the  data  type  Packet  can  be  found  in  Appendix  II.  A  brief  description  is  given  here. 

The  fields  of  a  packet  are  the  following: 

SeqNumber 

is  the  sequence  number  of  the  packet. 

Seqflnc 

is  the  incarnation  number  associated  with  the  sequence  number. 

AckNumber 

is  the  sequence  number  that  the  packet  is  acknowledging. 

Ackjffnc 

is  the  incarnation  number  of  the  acknowledgment  field. 

Ctl  is  the  control  field  of  the  packet. 

As  an  illustration  of  the  effects  of  an  event,  consider  the  ActiveOpen  event  (see  page  26).  Its  precondition 
states  that  it  can  fire  only  if  the  StateCf  the  node  is  Closed,  and  the  user  issued  an  active  open  command  by 
placing  the  value  Active  in  the  Command  buffer.  When  this  event  fires,  the  effects  specified  state,  for  instance, 
that  a  SYN  packet  is  sent  to  the  other  side  by  appending  it  to  the  OutPort  interface  variable.  It  is  also 
specified  that  the  StateOf  state  variable  becomes  SynSent. 

Finally,  the  Topology  section  states  that  there  are  two  stations.  Left  and  Right,  connected  by  a  medium  in 
each  direction  (i.e.,  OutPon@Left,  Buffer@LeftToRight,  and  InPort@Right  are  all  a  single  shared  queue). 

The  Properties  section  states  properties  concerning  the  correct  operation  of  the  system  that  will  be 
discussed  in  Section  3. 

The  SPEXification  given  in  Appendix  I  is  a  simplification  of  the  one  given  in  TCP  [12].  The  main 
differences  are: 

►  TCP  allows  connections  between  arbitrary  pairs  of  addresses  within  a  large  address  space.  As  in 
TCP,  the  SPEXification  assumes  this  addressing  function  is  performed  by  a  higher  (sub)  level,  so 
that  only  fixed  pair  of  nodes  need  be  considered. 


►  TCP  uses  a  sequence  number  and  an  initial  send  sequence  number  selection  algorithm  to  handle 
the  problems  of  distinguishing  incarnations.  TCP  sequence  numbers  correspond  roughly  to  a 
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concatenation  of  incarnation  and  sequence  numbers  in  our  specification.  TCP  sequence  numbers 
are  of  finite  size,  whereas  they  are  of  infinite  size  in  the  SPEXification. 

►  The  SPEXification  concerns  itself  only  with  the  connection-opening  phase  of  the  protocol;  it  does 
not  allow  closing  of  the  connection  in  the  middle  of  an  opening.  Likewise,  it  does  not  allow  data  to 
be  sent  while  a  connection  is  being  opened. 

►  When  a  RST  packet  arrives  at  a  node  that  is  in  SYNSENT  state,  the  TCP  remembers  whether  the 
connection  started  via  an  active  or  via  a  passive  open.  If  the  open  was  passive,  the  station  returns 
to  the  LISTEN  state  rather  than  closing  the  connection.  The  SPEXification  always  closes  the 
connection  after  a  reset.  This  modification  does  not  affect  the  functional  correctness  of  the 
protocol,  but  makes  the  corresponding  SPEXification  simpler. 


For  the  purposes  of  verifying  properties  of  the  three-way  handshake,  the  SPEXification  has  been  manually 
translated  into  an  algebraic  data  type  specification  that  can  be  understood  by  the  Affirm  system.  Appendix  II 
contains  the  generated  axioms  and  auxiliary  data  type  definitions  (e.g..  Packet,  QueueOfPacket)  in  Affirm 
syntax. 


2L. 


15 


3.  VERIFICATION 

3.1  Introduction 

This  section  discusses  the  verification  of  properties  concerning  functional  correctness  and  liveness.  The 
discussion  is  presented  in  terms  of  the  algebraic  style  data  type  specification  as  understood  by  Affirm. 

As  was  discussed  in  Section  1.1,  the  functional  correctness  of  a  connection  protocol  cannot  be  completely 
separated  from  the  succeeding  data  transfer  phase.  This  introduces  a  problem  as  to  the  instant  at  which  the 
claim  of  functional  correctness  should  be  made.  Ideally,  functional  correctness  should  state  that 

At  the  end  of  the  connection  phase,  both  stations  are  in  the  Established  state  and  are 
synchronized,  which  means  that  "old"  data  will  not  be  accepted,  but  "new”  data  will  be. 

Therefore,  it  would  be  necessary  to  describe  at  least  part  of  the  data  transfer  protocol  as  well. 

Because  the  data  transfer  has  been  omitted  from  the  specification,  a  modified  version  of  this  property  must 
be  used.  The  following  sections  describe  this  in  more  detail. 

3.2  Functional  Correctness 

Consider  now  the  Junctional  correctness  of  the  protocol,  as  stated  above,  but  from  only  one  node’s  point  of 
view:6 


(StateOf  =  Established)@Right 
imp  Seq  #  T oReceive@ Left  =  Seq  #  ToSend@ Right  and 
Incarnation #  ln@Left  =  Incarnation  #Out@Right ; 


In  English,  this  says  that  if  the  station  on  the  Right  side  is  in  the  Established  state,  then  the  connection  is 
synchronized  for  data  flowing  out  of  this  node. 

This  property  is  proved  to  be  invariant  by  inductive  proof  methods  which  are  used  for  abstract  data  types. 
Work  with  this  specification  showed  that  this  theorem  was  not  strong  enough  to  be  used  in  an  inductive  proof, 
for  the  following  reason.  Careful  study  of  the  protocol  shows  that  it  is  possible  for  the  above  properties  to 
hold  in  the  SynSent  state  also,  when  simultaneous  active  open  commands  are  issued  at  both  nodes,  as  follows: 
one  side  may  be  in  the  SynSent  state  and  may  already  have  received  an  acknowledgment  for  its  SYN  packet; 
this  side  would  not  enter  the  Established  state  until  it  receives  the  SYN  packet  from  the  other  side.  This 
situation  is  characterized  by  the  fact  that  OldUnack  (the  oldest  unacknowledged  sequence  number)  is  not  ISS 
anymore.  Since  this  side  has  received  an  acknowledgment  for  its  SYN,  it  can  be  sure  that  the  other  side 
knows  its  Seq#ToSend  and  its  Incarnation# Out. 


kphe  notation  P<§  n  means  P  is  to  be  evaluated  in  node  n. 
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Hence  the  statement  of  functional  correctness  must  be  strengthened  (for  one  side  only)  as  follows: 
Theorem  FC: 

( (StateOf  =  Established)  or  ((StateOf  =  SynSent)  and  01dUnack~  =  ISS)  )@Right 
imp 

Seq  # T  oRecei  ve@Left = Seq  # T  oSend@Right  and 
Incarnation  #  In@Left  =  Incarnation  #  Out@Right ; 


This  need  to  strengthen  or  generalize  a  theorem  in  order  to  prove  its  invariance  is  typical  of  inductive  proof 
methods  used  for  abstract  data  types. 

Notice  that  this  strengthened  statement  implies  the  weaker  one,  so  that  proving  the  stronger  one  proves  the 
weaker  one  as  well. 

Figure  3-1  contains  a  proof  tree  for  this  theorem  produced  by  the  Affirm  system;  the  lemmas  and 
definitions  used  are  given  in  Figure  3-2  (these  figures  contain  axioms  and  theorems  stated  using  Affirm 
syntax;  the  correspondence  to  SPEX  syntax  should  be  obvious).7  The  proof  follows  an  inductive  argument 
over  all  possible  events  in  the  system.  Broadly  speaking,  this  can  be  expressed  as  the  following:  given  a  goal 
state  (e.g..  Established),  examine  how  each  event  can  move  the  system  into  that  state  (e.g.,  ReceiveAck  event  in 
SynReceived  state).  In  general,  there  are  many  states  from  which  the  system  may  move  into  the  goal  state. 
Considering  now  each  of  those  states,  one  uses  the  inductive  hypothesis  to  try  to  prove  the  theorem. 

After  some  examination  of  the  proof  tree,  it  is  possible  to  see  that  most  cases  follow  directly  from  the 
inductive  hypotheses;  this  can  be  seen  in  the  proof  tree  by  looking  at  the  branches  and  noticing  where  only  an 
invoke  IH  command  (possibly  preceded  or  followed  by  some  replace,  cases  and  invoke  commands)  was  given. 
Now  the  cases  are  examined  which  do  not  follow  directly  from  the  inductive  hypotheses.  i.e.,  involve  the 
application  of  some  lemmas. 

Consider  what  happens  when  a  ReceiveAck@Right  occurs  («-«-<  1  ).8  The  relevant  case  to  consider  has  the 
node  at  right  in  SynSent  or  in  SynReceived,  and  the  incoming  acknowledgment  has  the  current  incarnation 
number  (since  otherwise  the  packet  would  be  discarded  as  old).  In  other  words,  the  incarnation  number  in 
the  packet  is  equal  to  Incarnation  #Out@Right.  (See  hypotheses  of  theorem  AcksAndSyns  in  Fig.  3-2, 
applied  at  *-*-<2.)  But  if  the  incarnation  number  is  current,  then  there  must  have  been  a  SYN  packet  in  the 
past  which  this  current  packet  acknowledges  (see  definition  of  HasSyn,  invoked  at  «-«-<3).  Thus,  the  current 
ACK  carries  the  same  incarnation  number  that  the  SYN  carried,  which  means  that  the  station  at  left  has  its 
Incarnation# In  set  to  the  incarnation  number  of  that  SYN  packet.  Therefore,  we  can  conclude  that 
Incarnation#  Out®  Right  =  Incarnation#  In@Left. 

7Numbers  on  the  left  should  be  ignored;  they  result  from  bookkeeping  in  Affirm. 

Q 

Indicators  of  the  form  ♦**-<n  are  used  to  point  to  the  corresponding  places  in  the  proof  tree 
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theorem  Synchronized.  StateOf (S, Right)  •  Established 

or  StateOf (S, Right)  •  SynSent  and  01dUnack(S, Right)  -•  I SS (Right) 
imp  synchronized(S) ; 

Synchronized  uses  EorSSimpEorSRX,  SynchNoLorCorSSX.  AcksAndSynsX,  FrontlnQX, 
Seq#ToSendValsX,  and  Seq#ToRece1veValX. 


proof  tree: 

68:!  Synchronized 

apply  EorSSimpEorSR  {proved  by  Schwabe  using  Affirm  120  on  4-Feb-81  In 
transcript  <SCHWABE>Afr irmtranscript .3- FEB-81 .2} 

70:  54  put  S'*S 

74:  56  employ  Induction(S) 

Empty: 

Immediate 


76: 

apr : 

56  employ  Normal Form( 1 1S) 

78: 

ActiveOpen: 

57  cases 

80: 

65  Invoke  IN 

82: 

66  replace 

84: 

67  Invoke  synchronized  |  all 

1 

84: 

(proven! ) 

221: 

PassiveOpen : {Synchron 1  zed ,  apr:} 

58  cases 

223 

125  Invoke  IN 

225 

126  Invoke  synchronized  |  all 

1 

225 

(proven!) 

227 

LoseMessage:{Synchron1zed,  apr:} 

59  invoke  IN 

229 

128  Invoke  synchronized  |  all 

1 

233 

(proven!) 

231 

Timeout: {Synchronized,  apr:} 

60  Invoke  IH 

233 

130  Invoke  synchronized  |  all 

1 

233 

(proven!) 

235 

Rece1veRst:{Synchronized,  apr:} 

61  cases 

237 

131  employ  Norma1Form( 1 ' ) 

239 

Left: 

132  Invoke  IN 

241 

134  Invoke  synchronized  ( 

all 

241 

(proven!) 

243 

Right: 

133  Invoke  IH 

263 

136  Invoke  synchronized  | 

all 

253 

:->  (proven!) 

88: 

ReceiveAck: {Synchronized,  apr:} 

62  cases 

90: 

69  employ  Normal Form( i ’ ) 

92: 

Left: 

70 

Invoke  IH 

94: 

72 

Invoke  synchronized  I  all  1 

94: 

(proven! ) 

96: 

Right: 

71 

Invoke  IH 

98: 

74 

replace 

105 

75 

invoke  synchronized  |  all  | 

107 

76 

apply  AcksAndSyns 

109 

77 

put  pk  *  Front(Medium(ss'. 

and  S*ss' 

Left)) 

111 

78 

apply  FrontlnQ 

113 

79 

put  Q  ■  Medium(ss'.  Left) 

116 

80 

replace 

121 

81 

Invoke  PreCond  |  -4  :  -3  | 

123 

82 

apply  SeqfToSendVals 
put  S>ss' 

125 

83 

127 

84 

Invoke  IncomingAckA'Val Id  |  all 

1  *-*-<3 

129 

85 

Invoke  HasSyn 

131 

86 

replace 

133 

87 

apply  Seq#ToReceiveVal 
put  S*ss' 

135 

88 

136 

(proven! ) 

Figure  3*1:  Proof  tree  for  the  functional  correctness  of  the  three-way  handshake 
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137:  ReceiveSyn : {Synchronized ,  apr:} 


63 

cases 

139 

90 

invoke  IH 

141 

91 

replace 

143 

92 

invoke  synchronized 

145 

93 

cases 

150 

94 

replace 

161 

95 

apply  SynchNoLorCorSS 

163 

97 

put  S*ss' 

165 

98 

repl ace 

(proven! ) 

167:  ReceiveSynAck:{Synchronized ,  apr:} 

64  cases 

169:  99  employ  Normal form( i ' ) 

171:  Left: 


173 

175 

177 

179 

181 

181 

183 

185 

187 

189 

191 

193 

195 

199 

201 

203 

205 

207 

209 

211 

213 

215 

217 

219 


100  invoke  IH 

102  invoke  synchronized  |  all  | 

103  cases 

104  replace 

105  apply  SynchNoLorCorSS 

106  put  S*ss‘ 

(proven! ) 

Right:{Synchronized,  apr:.  ReceiveSynAck : } 

101  invoke  IH 

108  invoke  synchronized  f  all  | 

109  apply  AcksAndSyns 

110  put  S*ss' 

and  pk  =  F ront (Med ium( ss '  ,  Left)) 

111  apply  FrontlnQ 

112  put  Q  =  Medium(ss',  Left) 

113  replace 

114  invoke  IncomingAck#Val id  |  last  |  ,  PreCond 

115  replace 

116  invoke  HasSyn 

117  invoke  PreCond 

118  replace 

119  apply  Seq#ToSendVals 

120  put  S*ss’ 

121  replace 

122  apply  SeqffToReceiveVal 

123  put  S«ss’ 

124  replace 
(proven ! ) 


I  1  I 


Figure  3-1:  Proof  tree  (continued) 
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theorem  Synchronized,  StateOf(S,  Right)  =  Established 
or  StateOf(S,  Right)  =  SynSent 
and  OtdUnack(S,  Right)  -  =  ISS(Right) 
imp  synchronized(S); 

theorem  AcksAndSyns,  pk  in  Medium(S.  Left) 
and  StateOf(S,  Left)  -  =  Listen 
and  StateOf(S,  Left)  -  =  Closed 
and  Inc  #  Ack(pk)  =  Incarnation  #  Out(S,  Right) 
and  (Control(pk)  =  ack)  or  (Control(pk)  =  synack) 
imp  HasSyn(S.  pk); 

theorem  FrontlnQ,  O-  «  NewQueuOf  Packet  imp  Front(O)  in  0; 

theorem  Seq  *  ToSendVals.  StateOffS,  Right)  -  =  Dosed 
and  StateOf(S,  Right)  -  =  Listen 
imp  Seq  it  ToSend(S,  Right)  =  1  +  ISS(Right); 

theorem  Seq  #ToReceiveVal.  StateOf(S,  Right)  -  =  Closed 
and  StateOf(S,  Right)  -  =  Listen 
and  StateOf(S,  Left)  =  SynReceived 
or  StateOf(S,  Left)  -  Established 
and  Incarnation  tfOut(S,  Right)  =  Incarnation  » lr»(S,  Left) 
imp  Seq  #ToReceive(S.  Left)  =  1  +  ISS(Right); 

theorem  EorSSimpEorSR.  StateOf(S,  Right)  =  Established 
or  StateOf(S.  Right)  =  SynSent 
and  OldUnack(S.  Right)  -  =  ISS(Right) 
imp  StateOf(S,  Left)  =  Established 
or  StateOf(S,  Left)  =  SynReceived; 

theorem  SynchNoLorCorSS,  StateOfjS,  Right)  =  Established 
or  StateOf(S,  Right)  =  SynSent 
and  OfdUnack(S,  Right)  ~  *  ISS< Right) 
imp  StateOf(S,  Left)  -  =  Listen 
and  StateOf(S,  Left)  -  =  Dosed 
and  StateOf(S,  Left)  -  =  SynSent, 
define  synchronized(S) 

=  =  (  Seq  #ToReceive(S,  Left)  =  Seq  #ToSend(S,  Right) 
and  Incarnation  » ln(S,  Left)  =  Incarnation  A? Out (S,  Right)), 

HasSyn(S,  pk) 

=  =  some  SS,  SS'.pk' 

(  SS  join  SS'  =  S 
and  pk  in  Medium(SS.  Right) 
and  lnc#Seq(pk‘)  =  Inc  At  Ack(pk) 
and  lnc#Seq(pk')  =  Incarnation  #ln(S,  Left) 
and  if  Control(pk)  =  synack 
then  Control(pk')  =  syn 

else  (Control(pk')  =  syn  or  Control(pk’)  =  synack)); 


Figure  3-2:  Theorems  and  definitions  used  in  the  proof  of  the  three-way  handshake 
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For  the  sequence  numbers  to  correspond,  it  suffices  to  see  that,  if  the  state  of  a  node  is  not  Listen  or 
Closed,  then  its  Seq #ToSend  is  always  equal  to  1SS  + 1  (Seq#ToSend  will  not  change  until  data  is  sent  --  see 
theorem  SeqtfToSendVals,  applied  at  *-«-<4),  and  that  all  SYN  packets  carry  ISS  as  their  sequence  numbers. 
Since  the  SeqtfToReceive  is  taken  from  the  SYN  packet,  it  must  perforce  be  1SS+1  (see  theorem 
Seq JifToReceive Vais,  applied  at  «-*-<5).  Therefore  Seq#ToReceive@Left=Seq#ToSend@Right. 

The  next  relevant  case  is  when  a  ReceiveSyn@Left  occurs  (*-«-<6).  This  can  be  correct  only  if  the  node  at 
left  is  in  either  Listen  or  SynSent:  all  other  cases  either  cause  an  error  or  ignore  the  packet.  But  a  careful 
examination  of  the  state  machine  shows  that  it  is  not  possible  to  have  the  station  at  one  side  in  either  Listen  or 
SynSent  and  the  other  in  either  Established  or  in  SynReceived  with  OldUnack  ~=  ISS  (theorem 
SynchNoLorCorSS,  applied  at  «-*-<7).  Therefore  this  situation  really  cannot  occur. 

The  other  relevant  cases  are  when  a  ReceiveSynAck  occurs  at  either  node.  If  it  happens  at  the  node  at  right 
then  the  proof  follows  the  same  argument  as  the  case  for  the  ReceiveAck@Right  If  it  happens  at  the  node  at 
left,  then  the  proof  follows  the  reasoning  for  the  case  ReceiveSyn@Left. 

3.3  Liveness 

Another  useful  property  that  this  protocol  possesses  is  Liveness,  which  states  that  either  some  event  in  the 
system  is  enabled  or  the  system  is  in  its  final  state.  Since  open  events  are  user  generated,  these  events  are 
ignored,  and  we  assume  that  the  system  starts  in  a  state  where  neither  side  is  in  the  Closed  state  and  both  sides 
are  not  passively  listening.  In  this  case,  it  is  expected  that  the  correct  protocol  will  complete  the  connection- 
establishment  and  reach  a  final  global  state  in  which  both  sides  have  reached  the  Established  state. 

In  order  to  prove  such  a  property,  however,  it  is  necessary  to  prevent  certain  sequences  from  actually  being 
valid  for  the  system.  These  are  sequences  composed  entirely  of  LoseMessage  or  Timeout  events.  Such 
sequences  reflect  fairness  assumptions  on  the  medium,  as  well  as  finite  capacity.  Thus,  restrictions  must  be 
made  in  the  specification  to  insure  the  fairness  of  the  medium.  These  restrictions  are  incorporated  by 
including  a  limit  on  the  number  of  occurrences  of  the  LoseMessage  event,  as  well  as  on  the  size  of  the 
medium. 

Accordingly,  the  number  of  occurrences  of  the  LoseMessage  event  is  limited  by  having  an  extra  auxiliary 
counter  such  that  LoseMessage  an  be  enabled  only  when  the  counter  is  positive,  and  each  time  LoseMessage 
fires  it  decreases  the  counter  by  one.  It  is  set  to  some  constant  value  each  time  a  message  or  an 
acknowledgment  is  received.  This  constant  value  must  be  finite,  but  can  be  arbitrarily  large. 

The  capacity  of  the  medium  can  be  taken  into  consideration  by  augmenting  the  precondition  of  all  events 
that  put  something  into  the  medium  with  a  test  to  see  if  the  length  of  the  corresponding  queue  is  less  than  a 
certain  constant,  which  again  must  be  finite  but  arbitrarily  large.  This  rules  out  behaviors  in  which  a  node 
times  out  over  and  over,  without  anything  else  happening  in  the  system. 
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With  these  modifications  introduced,  an  attempt  was  made  to  prove  that  this  protocol  is  alive,  i.e.,  it 
satisfies 

Theorem  Liveness: 

For  all  S,i 


(~PreCond(S,ReceiveAT)  and  ~PreCond(S, Timeout) 
and  ~PreCond(S,LoseMessage)  and  StateOf--  =  Closed]®  i 
and  ~(StateOf@i  =  Listen  and  StateOf®OppositeSide(i)  =  Listen) 
imp  (StateOf  =  Establis’  °d)@Left  and  (StateOf  =  Established)®  Right ; 

where  AT={Ack,Syn,SynAck,Rst}. 

An  inductive  proof  goes  through  for  all  cases  except  for  ReceiveRst.  After  some  investigation,  it  was  found 
that  there  is  a  scenario  in  which  it  is  possible  for  the  two  nodes  to  end  in  the  Closed  state,  which  is  a 
contradiction  of  the  theorem!  Figure  3-3  shows  this  scenario  (with  SEQ  treated  as  a  single  item  representing 
both  the  sequence  number  and  the  incarnation  number). 

This  situation  is  considered  an  error  because  old  duplicate  packets  in  the  medium  prevent  a  connection 
from  being  established.  Note  that  this  is  a  liveness  error,  not  a  safety  error,  since  nothing  bad  happens,  i.e.,  no 
incorrect  synchronization  or  data  transfer  takes  place,  but  the  intended  progress  does  not  occur. 

Another  situation  in  which  there  is  no  progress  may  occur  because  of  the  introduced  protocol  simplification 
that  a  node  always  returns  to  Closed  state  when  a  RST  packet  arrives.  Note  that  this  is  not  the  scenario 
described  above. 

Interestingly,  if  data  packets  are  allowed  to  be  sent  this  scenario  can  be  continued  in  such  a  way  that  it 
actually  accepts  data  incorrectly.  It  is  sufficient  for  the  appropriate  old  data  packets  to  arrive  at  Node  A  at  the 
point  Node  A  entered  the  Established  state  and  before  any  RST  packets  were  sent  by  Node  B;  this  is 
indicated  in  Figure  3-3.  However,  it  should  be  noted  that  this  situation  depends  on  an  extremely  unlikely 
timing  of  message  exchanges,  which  is  not  expected  to  be  of  practical  significance. 

This  incorrect  data  can  be  avoided  with  a  small  change  in  the  protocol.  Work  is  under  way  to  verify  that  a 
corrected  version  of  the  three-way  handshake  avoids  it. 

In  [1).  Berthomieu  discusses  the  verification  of  other  types  of  liveness  properties  in  algebraically  described 
state  transition  systems. 
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Node  A 

CLOSED 

CLOSED 

act.  Open 

<SEQ  =  200XCTL  =  S YN>  ->  ... 

(delayed) 

<-  <SEQ  =  300XCTL = S  YN> 

act.  OPEN 

SYNSENT 

SYNSENT 
...  rev  SYN 

SYNSENT 

SYNRECF.1VED 

<-  <SEQ  =  301XACK  =  201XCTL  =  ACK> 

snd  ACK 

rev  ACK 

SYNSENT 

<-  <SEQ  =  100XCTL  =  SYN>  old  duplicate  !! 

SYNRECEIVED 

rev  SYN 

ESTABLISHED 

SYNRECEIVED 

snJ  ACK 

<SEQ  =  201XACK.  =  101XCTL  =  ACK>  ->  bad  A  CK  !! 

***  bad  data  might  be  accepted  here  *** 
e.g.,  <-  <SEQ  =  101XDAT A> 

rev  ACK 

ESTABLISHED 

SYNRECEIVED 

<-  <SEQ  =  101XCTL = RST> 

snd  RST 

rev  RST 

CLOSED 

<-  <SEQ  =  300XCTL = S  YN>  original  delayed  syn 

SYNRECEIVED 

rev  S  YN 

CLOSED 

SYNRECEIVED 

snd  RST 

<SEQ = OX  ACK  =  301XCTL = RST>  -> 

rev  RST 

discard-  bad  ACK  At 

rev  ACK 

<-  <SEQ  =  30 IX  ACK  =  201XCTL  =  ACK> 

snd  ACK 

CLOSED 

SYNRECEIVED 

snd  RST 

<SEQ  =  201XCTL  =  RST>  -> 

rev  RST 

CLOSED 

CLOSED 

Figure  >3:  Example  of  a  liveness  error  in  the  three-way  handshake 
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4.  CONCLUSIONS 


This  report  has  presented  an  exercise  in  the  verification  of  properties  of  a  connection-establishment 
protocol.  A  specification  language  tailored  to  the  need  of  communications  protocols  has  been  proposed,  and 
its  relation  to  a  semi-automated  verification  system  discussed.  This  language  was  then  used  to  specify  a 
connection  protocol  currently  being  used,  and  certain  errors  were  uncovered  using  the  verification  system, 
although  the  major  portion  of  the  protocol’s  operation  was  shown  to  be  correct. 

This  work  is  part  of  an  ongoing  project  to  develop  better  protocol  specification  and  analysis  techniques; 
further  work  is  described  in  [13, 18].  Our  preliminary  experience  indicates  that  the  combination  of  state 
transition  and  abstract  data  type  specification  methods  being  pursued  provides  a  reasonably  convenient  and 
powerful  approach  to  these  problems. 


I.  SPEXIFICATION  OF  THE  THREE-WAY 
HANDSHAKE 


Node(Station)[ 

State  Variables 

l 

ISS, 

Incarnation#  In, 

Incarnation#  Out, 

OldUnack, 

Seq#ToSend, 

Seq  #  T  oReceive 
:Nat, 

TimeoutBuffer :  OueueOfPackets, 


Interfaces 

[ 

Exported:: 

Command :  Command, 
StateOf :  SysState, 

Internal:: 

InPort , 

OutPort 

:OueueOfPackets ; 


|  Initial  Sand  Sequence  * 

|  Incarnation  #  of  Incoming  packets 
|  Incarnation  xr  of  outgoing  packets 
|  Oldest  unacknowledged  seq.  * 

|  Seq  S  to  put  in  the  next  outgoing  packet 
|  Next  expected  seq  xr 
f  Nat  stands  tor  Natural 

|  butler  with  packets  sent  and  not  acknowledged 


|  One  ol  {Active, Passive. Null) 

|  State  ot  this  side  of  the  connection 

|  msgs  coming  in 
|  msgs  going  out 


Initial  State 

[ 

Incarnation  #  Out  =  Maxval(lnPort  Append  OutPort)  and|  Maxvai  produces  a  unique  value 

|  see  Properties  section 

Incarnation#  In  =  Oand 
Seq#ToSend  =  Oand 
Seq#ToReceive  =  Oand 
StateOf  =  Closed  and 
OldUnack  =  0, 

TimeoutBuffer  =  NewQueueOfPackets ; 


Events 

[  |  Events  and  their  preconditions 

ActiveOpen  :  PreCond  is  StateOf  =  Closed  and  Command  =  Active, 

PassiveOpen  :  PreCond  is  StateOf  =  Closed  and  Command  =  Passive, 

Timeout :  PreCond  is  TimeoutBuffer  -  ■  NewQueueOfPackets, 

ReceiveRst :  PreCond  is  InPort  ~  =  NewQueueOfPackets  and  Control(Front(lnPort))  =  rst, 
Receive Ack  :  PreCond  is  lnPort~  *  NewQueueOfPackets  and  Control(Front(lnPort))  *  ack, 
ReceiveSyn  :  PreCond  is  lnPort~  *  NewQueueOfPackets  and  Control(Front(lnPort))  *  syn, 
ReceiveSynAck :  PreCond  is 

lnPort~  =  NewQueueOfPackets  and  Control(Front(lnPort)) «  synack 

] 
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Behavior 

[ 

we  deline  some  auxiliary  predicates  and 
\lunctions  to  improve  readability  ol  the  specification 

define  IncomingAck#  Valid  =  = 

( AckNumber(Front(lnPort))  =  +  OldUnack)  and 
Ack  #  lnc(Front(lnPort))  =  Incarnation#  Out; 

|  Acknowledgment  lor  X  has  Ack  >X«t 


define  IncomingSeq  #  Valid  =  = 

( SeqNumber{Front(lnPort))  =  Seq#ToReceive)  and 
Seq  #  lnc(Front(lnPort))  =  Incarnation#  In; 


ActiveOpen:: 

Command  «■  Null, 

Incarnation# Out  *■  Maxval(lnPort  Append  OutPort), 

OldUnack «-  ISS, 

Seq  #  T oSend  ♦■  +  ISS 
StateOf  *•  SynSent 
TimeoutBuffer  «- 

NewOueueOfPackets  Add  pkt(!SS,Maxval(lnPort  Append  Outport), AnyNat,AnyNat,syn) 
OutPort  «- 

Outport  Add  pkt{ISS,Maxval(lnPort  Append  Outport), AnyNat.AnyNat.syn) ; 


PassiveOpen: 

Command  *■  Null, 

StateOf  *■  Listen, 

TimeoutBuffer  «■  NewOueueOfPackets; 

ReceiveRst:: 

StateOf  «- 

if  StateOf  =  SynSent  and  Incoming  Ack#  Valid 
then  Closed 
else  if  StateOf  =  Listen 
then  Listen 

else  if  IncomingSeq#  Valid 
then  Closed 
else  StateOf, 
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TimeoutBuffer  «- 

ifStateOf  =  SynSentand  IncomingAck#  Valid 
then  NewQueueOfPackets 
else  if  IncomingSeq  #  Valid 
then  NewQueueOfPackets 
else  TimeoutBuffer, 

InPort «-  Remove(lnPort), 


ReceiveAck:. 

OldUnack  *■ 

if  StateOf  =  SynSent 
then  if  IncomingAck  #  Valid 
then  +  OldUnack 
else  OldUnack 

else  if  StateOf  =  SynReceived 

then  if  IncomingAck#  Valid  and  IncomingSeq#  Valid 
then  +  OldUnack 
else  OldUnack 
else  OldUnack, 

StateOf  *■ 

if  StateOf  =  SynReceived 

then  if  IncomingAck#  Valid  and  IncomingSeq#  Valid 
then  Established 
else  SynReceived 
else  StateOf, 

TimeoutBuffer  «- 

if  StateOf  =  Closed  or  StateOf  =  Listen 
then  NewQueueOfPackets 
else  if  StateOf  =  SynReceived 

then  if  IncomingAck# Valid  and  IncomingSeq# Valid 
then  DeletePacket(TimeoutBuffer,Seq  #  T oSend) 
else  TimeoutBuffer 
else  if  StateOf  =  SynSent 
then  if  IncomingAck  #  Valid 

then  DeletePacket(TimeoutBuffer,Seq  #ToSend) 
else  TimeoutBuffer 
else  TimeoutBuffer, 
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OutPort  «- 

if  StateOf  ■  Ciosed  or  StateOf  *  Listen 
or  ((StateOf  =  SynSent)  and  -Incoming  Ack  #  Valid) 
then  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 

Ack  #  lnc(Front(lnPort)), 

AnyNat.AnyNat, 

rat) 

else  if  StateOf  =  SynReceived 

then  if  -IncomingSeq#  Valid 
then  OutPort 

Add  pkt(Seq  #  T oSend, Incarnation  #  Out, 
Seq  #ToReceive, Incarnation#  In, 
ack) 

else  if  -Incoming Ack#  Valid 
then  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 
Ack  #  lnc(Front(lnPort)), 
AnyNat.AnyNat, 
rst) 

else  OutPort 
else  OutPort, 


InPort  <-  Remove(lnPort) ; 

ReceiveSyn:: 

Incarnation# Out  *■ 
if  StateOf  *  Listen 

then  Maxval(lnPort  Append  OutPort) 
else  Incarnation# Out, 

Incarnation  #  In  «- 

if  ((StateOf  =  Listen)  or  StateOf  *  SynSent) 
then  Seq  #  lnc(Front(lnPort)) 
else  Incarnation  #  In, 

OldUnack  «■ 

if  StateOf  =  Listen 
then  ISS 
else  OldUnack, 

Seq  #  ToSend  *■ 
if  StateOf  =  Listen 
then  +  ISS 
else  Seq  #  ToSend , 

Seq#ToReceive  «■ 

if  StateOf  -  Listen  or  StateOf  *  SynSent 
then  +  SeqNumber(Front(lnPort)) 
else  Seq  #  T oReceive, 
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StateOf  «- 

ifStateOf  =  Listen 
then  SynReceived 
else  if  StateOf  =  SynSent 
then  if  OldUnack  =  ISS 
then  SynReceived 
else  Established 
else  StateOf, 

TimeoutBuffer  *■ 
if  StateOf  =  Listen 
then  NewQueueOfPackets 

Add  pkt(lSS,Maxval(lnPort  Append  OutPort), 
+  SeqNumber(Front(lnPort)) 

,Seq  it  lnc(Front(lnPort)), 
synack) 

else  if  StateOf  =  Closed 

then  NewQueueOfPackets 
else  TimeoutBuffer, 


OutPort  *■ 

if  StateOf  =  SynSent 
then  OutPort 

Add  pkt(Seq  U  ToSend, Incarnation  #  Out, 

+  SeqNumber(Front(lnPort)) 

,Seq  U  lnc(Front(lnPort)), 
ack) 

else  if  StateOf  =  SynReceived  or  StateOf  =  Established 
then  if  IncomingSeq  #  Valid 
then  OutPort 
else  OutPort 

Add  pkt(Seq#  ToSend, 

Incarnation  it  Out, 

SeqtfToReceive, 

Incarnation  U  In, 
ack) 

else  if  StateOf  =  Listen 
then  OutPort 

Add  pkt(ISS,Maxval(lnPort  Append  OutPort), 

+  SeqNumber(Front(lnPort)) 

,Seq  U  lnc(Front(lnPort)), 
synack) 
else  OutPort 

Add  pkt{0’, Incarnation^  Out, 

+  SeqNumber(Front(lnPort)) 

,Seq  it  lnc(Front(lnPort)), 
rst), 


InPort  *•  Remove(lnPort) ; 
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ReceiveSynAck:: 

Incarnation  it  In  *■ 

if  (StateOf  =  SynSent)  and  IncomingAck  it  Valid 
then  Seq  #  lnc(Front(lnPort)) 
else  Incarnation#  In, 

OldUnack  *■ 

if  StateOf  =  SynSent 
then  if  IncomingAck#  Valid 
then  +  OldUnack 
else  OldUnack 

else  if  StateOf  =  SynReceived  or  StateOf  =  Established 
then  if  IncomingAck#  Valid  and  IncomingSeq#  Valid 
then  +  OldUnack 
else  OldUnack 
else  OldUnack, 

Seq#ToReceive  «- 

if  StateOf  =  SynSent 
then  if  IncomingAck# Valid 

then  +  SeqNumber(Front(lnPort)) 
else  Seq#ToReceive 
else  Seq# ToReceive, 

StateOf 

if  StateOf  =  SynSent  and  IncomingAck#  Valid 
then  Established 
else  StateOf, 

TimeoutBuffer  *■ 

if  StateOf  =  Closed  or  StateOf  =  Listen 
then  NewQueueOfPackets 
else  if  StateOf  =  SynSent 
then  if  IncomingAck# Valid 

then  DeletePacket(TimeoutBuffer, OldUnack) 
else  NewQueueOfPackets 
else  TimeoutBuffer, 
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OutPort  «- 

if  StateOf  =  Closed  or  StateOf  =  Listen 
then  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 

Ack  #  lnc(Front(lnPort)), 

AnyNat.AnyNat, 

rst) 

else  if  StateOf  =  SynSent 

then  if  IncomingAck  #  Valid 
then  OutPort 

Add  pkt(Seq  # ToSend, Incarnation  # Out, 

+  SeqNumber(Front(lnPort)), 

Seq  #  lnc(Front(lnPort)), 
ack) 

else  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 

Ack  #  lnc(Front(lnPort)), 

AnyNat.AnyNat, 

rst) 

else  if  StateOf  =  Established 
then  if  IncomingSeq  #  Valid 
then  OutPort 
else  OutPort 

Add  pkt(Seq  #  T oSend, 

Incarnation#  Out, 

Seq#ToReceive, 

Incarnation#  In, 
ack) 

else  if  StateOf  =  SynReceived 
then  if  ~ IncomingSeq# Valid 
then  OutPort 

Add  pkt(Seq  #  ToSend, Incarnation  #  Out, 
Seq  #  T  oReceive, Incarnation  #  In, 
ack) 

else  if  -IncomingAck# Valid 
then  OutPort 

Add  pkt(AckNumber(Front(lnPort)), 

Ack  #  lnc(Front(lnPort)), 

AnyNat.AnyNat, 

rst) 

else  OutPort, 


InPort  «■  Remove(lnPort); 


Timeout:: 

OutPort  «■  OutPort  Append  TimeoutBuffer ; 

1 

|  Node  Station  |] 
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Node(Medium)[ 

State  Variables[|  No  stale  variables  |] 

Interfaces 

l 

Exported:: 

Buffer :  OueueOfPacket ; 

] 

Initial  State 

[  Buffer  =  NewOueueOfPacket ;  ] 

Events[  LoseMessage :  PreCond  is  Buffer  ~  =  NewOueueOfPacket ;] 
Behavior 

l 

LoseMessage:: 

Buffer  «■  Remove(Buffer) ; 

] 

|  Node  Medium)] 

Topology 

[  |  There  is  a  medium  RightToLeft  and  a  medium  Left ToRight 

|  There  are  two  instances  o t  node  type  Station:  Left  and  Right 

Instances:: 

RightToLeft, LeftToRight :  Medium, 

Left.Right :  Station  ; 

Connections:: 

lnPort@  Left, OutPort®  Right  <— >  Buffer@RightToLeft, 
OutPort@Left,lnPort@Right  <— >  Buffer@LeftToRight; 

] 

Properties 

[ 

assume  Maxval(Q), 
forall  pk( 

pk  in  O  imp  (Maxval(O)  >  Seq  #  Inc(pk)  and  Maxval(O)  >  Ack#  Inc(pk)) 

), 


assert  CorrectSynch, 

((StateOf  =  Established)  or  StateOf  =  SynSent  and  OldUnack~  « ISS)@Right  imp 
Seq #ToSend@ Right  *  Seq  #ToReceive@  Left  and 
Incarnation  #Out@ Right  ■  Incarnation  #  In @ Left , 

assert  Liveness, 

For  all  i  |  /  can  be  one  of  { Lett. Right) 

(  ~PreCond(ReceiveAck)  and  -PreCond(ReceiveSyn)  and 
~PreCond(ReceiveSynAck)  and  -PreCond(ReceiveRst)  and 
-PreCond (Timeout)  and  -PreCond(LoseMessage)  and  StateOf-  *  Closed)@i 
and  -  (StateOf  @i  =  Listen  and  StateOf  @OppositeSide(i)  *  Listen) 
imp  (StateOf  *  Established)®  Left  and  (StateOf  *  Established)®  Right ; 


] 
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II.  AXIOMS  GENERATED  FROM  THE 
SPEXIFICATION  OF  THE  THREE-WAY 
HANDSHAKE 


The  axioms  that  follow  contain  the  translation  of  the  SPEXification  of  the  three-way  handshake  given  in 
Appendix  1.  The  medium  interface  variables  (InPort,  OutPort  and  Buffer)  have  been  collapsed  into  the 
variable  Medium.  The  precondition  of  event  e  is  called  PreCond(S,e).  The  Command  interface  variable  has 
been  eliminated,  since  it  is  not  really  necessary  when  analyzing  the  properties  of  the  system  specified. 


11.1  Three-Way  Handshake 


type  ThreeWay; 

needs  types  Event.SequenceOfEvent, Packet, QueueOf Packets, SysState, Side; 

declare  Q.q.q':QueueOf  Packets; 

declare  seq#,seg#,ack#,snd#  integer; 

declare  cf:ControlField; 

declare  S.SS.SS':SequenceOtEvent; 

declare  pe:Event; 

declare  pk.pk’-.Packet; 

declare  i,ii,j:Side; 

interface  ISS(i):lnteger; 

interface 

TimeoutBuffer(S.i), 

Medium(S.i) 

QueueOfPackets; 

interface 

StateOf(S.i) 

SysState; 

interface 

Maxval(q), 

Incarnation  9  In(S.i), 

Incarnation  9  Out(S.i), 

OtdUnack(S.i). 

Seq#ToSend(S,i), 

Seq  #  ToReceive(S.i) 
integer; 

interface  lnduction(S):Boolean; 

(auxiliary  (unctions  to  help  in  the  readability  of  the  axioms) 

interface  PreCond(S.pe), 

Incoming  Ack  9  Valid(S.i), 

IncomingSeq  9  Valid(S.i) 

:  Boolean; 

define  (auxiliary  function  definitions) 

PreCond(S,ActiveOpen(i))  *  *  StateOf(S.i) «  Closed. 
PreCond(S.PassiveOpen(i))  =  «  StateOf (S.i)  *  Closed, 
PreCond(S,Timeout(i))  *  »  TimeoutBuffer(S.i)  -  *  NewOueueOfPackets, 
PreCond(S,LoeeMessage(i))  *  .  Medium(S.i)  *  •  NewOueueOfPackets, 
PreCond(S,Receiveflst(i))  ■  * 

( Medium(S,OppositeSide<i))  -  «  NewOueueOfPackets)  and 
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Control(Front(Medium(S,OppositeSide(i))))  =  rst, 
PreCond(S,ReceiveAck(i))  =  = 

( Medium(S,OppositeSide(i))  -  =  NewOueueOfPackets)  and 
Control(Front(Medium(S,OppositeSide(i))))  =  ack, 

PreCond(S.ReceiveSyn(i))  =  = 

( Medium(S,OppositeSide(i))  -  =  NewOueueOfPackets)  and 
Control(Front(Medium(S.OppositeSide(i))))  =  syn, 

PreCond(S.ReceiveSynAck{i))  =  = 

( Medium(S,OppositeSide(i))  -  =  NewOueueOfPackets)  and 
Control(Front(Medium(S,OppositeSide(i))))  =  synack, 

Incoming  Ack#  Valid(S.i)  =  = 

(  AckNumber(Front(Medium(S,OppositeSide(i))))  =  1  +OldUnack(S,i))  and 
Inc#  Ack(Front(Medium(S,OppositeSide(i))))  =  Incarnation  #Out(S,i), 

IncomingSeq  #  Valid(S.i)  =  = 

( SeqNumber(Front(Medium(S,OppositeSide(i))))  =  Seq  #ToReceive(S,i)) 
and  lnc#Seq(Front(Medium(S,OppositeSide(i))))  =  Incarnation  #ln(S,i); 


axioms  {Initial  State} 

Incarnation  #Out(Empty,i)  =  =  Maxval(Medium(Empty, Left)  Append 
Medium(Empty.Right)), 

Incarnation  #  In(Empty.i)  =  =  0, 

Ok)Unack(Empty,i)  =  =  0, 

Seq#ToSend(Empty,i)  =  =  0, 

Seq  #  ToReceive(Empty.i)  =  =  0, 

Medium(Empty.i)  =  =  NewOueueOfPackets, 

StateOf(Empty.i)  =  =  Dosed, 

TimeoutBuf1er(Empty,i)  =  =  NewOueueOfPackets; 


axioms  {Active  Open} 

Incarnation  #  Out(S  apr  ActiveOpen(i).j)  x  x 
if  i  =  j  and  PreCond(S,ActiveOpen(i)) 
then  Maxval(Medium(S,left)  Append  Medium(S, Right)) 
else  Incarnation  #Out{S,(), 

Incarnation  #  ln(S  apr  ActiveOpen{i),j)  *  x  Incarnation  #  In(S.j). 

Otdtlnack(S  apr  ActiveOpen{i),j)  x  x 
if  i  x  j  and  PreCond(S,ActiveOpen(i)) 
then  lSS(i) 
else  Ok)Unack(S.j), 

Seq  #  ToSendfS  apr  ActiveOpen(i).j)  =  x 
if  i  x  j  and  PreCond(S,ActiveOpen(i)) 
then  1  +  ISS(i) 
else  Seq  #  ToSend(S.j), 

Seq#ToReceive(S  apr  ActiveOpen(i),j)  x  =  Seq#ToReceive{S,i), 

SfafeOffS  apr  ActiveOpen(i),j)  =  x 
if  i  x  j  and  PreCond(S,ActiveOpen(i)) 
then  SynSent 
else  StateOf(S.j). 
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TimeoutBuffer(S  apr  ActiveOpen(i).j)  =  = 
if  i  =  j  and  PreCond(S.ActiveOpen(i)) 
than  NewOueueOfPackets 

Add  pkt(ISS(i),Maxval(Medium(S,Left)  Append  Medium(S, Right)), 
AnyNat.AnyNat.Syn) 
else  TimeoutBuffer(S,j), 

Medium(S  apr  ActiveOpen(i).j)  =  = 
if  i  =  j  and  PreCond(S,ActiveOpen{i)) 
then  Medium(S.i) 

Add  pkt(ISS(i).Maxval(Medium(S,Left)  Append  Medium(S.Right)), 
AnyNat.AnyNat.syn) 
else  Medium(S.j); 


axioms  {PassiveOpen) 

Incarnation  #Out(S  apr  PassiveOpen(i).j)  =  =  Incarnation  #  Out(S.j), 

Incarnation  XMn(S  apr  PassiveOpen(i).j)  =  =  Incarnation  M  In(S.j), 

OldUnack(S  apr  PassiveOpen(i).j)  =  =  OldUnack(S.j), 

Seq  9  ToSend(S  apr  PassiveOpen(i).j)  =  =  Seq  if  ToSend(S.j), 

Seq  tt  ToReceive(S  apr  PassiveOpen(i).j)  =  =  Seq  JirToReceive(S,j). 

StateOf(S  apr  PassiveOpen(i).j)  =  = 

H  i  =  j  and  PreCond(S,PassiveOpen(i)) 
then  Listen 
else  StateOf(S.j). 

Timeout Buffer(S  apr  PassiveOpen(j).i)  =  =  NewOueueOfPackets. 
Medium(S  apr  PassiveOpen(j).i)  =  =  Medium(S.i); 


axioms  {ReceiveRst} 

Incarnation  AfOut(S  apr  ReceiveRst(i).j)  =  =  Incarnation  U  Out(S.j), 

Incarnation# ln(S  apr  ReceiveRst(i).j)  =  =  Incarnation  #ln(S,j), 

OldUnackfS  apr  ReceiveRst(i).j)  =  =  OldUnack(S.j), 

Seq  #  ToSend(S  apr  ReceiueRst(i).j)  =  =  Seq  U  ToSend(S.j), 

Seq  #  T oReceivefS  apr  ReceiveRst(i)  ,j)  =  =  Seq  #ToReceive(S.j). 

StateOf(S  apr  ReceiveRst(i).j)  =  = 
if  i  =  j  and  PreCond(S,ReceiveRst(i))  then 
if  StateOI(S.i)  =  SynSent  and  lncomingAck#Valid(S,i) 
then  Dosed 

else  if  StateOf(S.i)  =  Listen 
then  Listen 

else  if  IncomingSeq  »  Valid(S.i) 
then  Dosed 
else  StateOf(S.i) 
else  StateOi(S.j). 

TimeoutBuffer(S  apr  ReceiveRst(i).j)  =  = 
if  i  =  j  and  PreCond(S,ReceiveRst(ij)  then 
if  StateOf(S.i)  *  SynSent  and  Incoming Ack#Valid(S,i) 
then  NewOueueOfPackets 
else  if  IncomingSeq  *  Valid(S.i) 

then  NewOueueOfPackets 
else  TimeoutBuffer(S.i) 
else  TimeoutBuffer(S.j), 


MediumfS  apr  ReceiveRst(i).j)  *  = 
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if 


i  =  j 

then  Medium(S.i) 

else  if  PreCond(S,ReceiveRst(i))  and  j  =  OppositeSide(i) 
then  Remove(Medium(S,j)) 
else  Medium(S.j); 


axioms  {ReceiveAck} 

Incarnation  #  Out(S  apr  ReceiveAck(i).j)  =  =  Incarnation  U  Out(S.j), 

Incarnation  #  ln(S  apr  ReceiveAck(i)J)  =  =  Incarnation  it  In(S.j), 

OldUnack(S  apr  ReceiveAck{i),j)  =  = 
if  i  =  j  and  PreCond(S,ReceiveAck(i)) 
then  if  StateOf(S,i)  =  SynSent 

then  if  IncomingAck  it  Valid(S.i) 
then  1  +  OldUnack(S.i) 
else  OldUnack(S.i) 
else  if  StateOf(S.i)  =  SynReceived 

then  if  IncomingAck  #Valid(S,i)  and  IncomingSeq  it  Valid(S.i) 
then  1  +  ddUnack(S.i) 
else  OkfUnack(S.i) 
else  OldUnack(S,i) 
else  OkJUnack(S.j), 

Seq  #ToSend(S  apr  ReceiveAck(i).j)  =  =  Seq  #  ToSend(S.j), 

Seq#ToReceive(S  apr  ReceiveAck(i).j)  =  =  Seq#ToReceive(S,j), 

StateOf(S  apr  ReceiveAck(i).j)  =  = 
if  i  =  j  and  PreCond(S,ReceiveAck(i)) 
then  if  StateOf(S.i)  =  SynReceived 

then  if  IncomingAck#  Valid(S.i)  and  IncomingSeq  #  Valid(S.i) 
then  Established 
else  SynReceived 
else  StateOf(S.i) 
else  StateOf(S.j), 

TimeoutBufferfS  apr  ReceiveAck(i).j)  =  = 
if  i  =  j  and  PreCond(S,ReceiveAck(i)) 
then  if  StateOf(S.i)  =  Closed  or  StateOf(S.i)  =  Listen 
then  NewOueueOfPackets 
else  if  StateOf(S.i)  =  SynReceived 

then  if  IncomingAck#  Valid(S.i)  and  IncomingSeq  #  Valid(S.i) 
then  DeletePacket(TimeoutBuffer(S,i),Seq  #ToSend(S,i)) 
else  TimeoutBuffer(S.i) 
else  if  StateOf(S.i)  =  SynSent 

then  if  AckNumber(Front(Medium(S,OppositeSide(i)»)  =  1  +  OldUnack(S.i) 
then  De!etePacket(TimeoutBuffer(S,i)  ,Seq  #  T oSend(S.i)) 
else  TimeoutBuffer(S.i) 
else  TimeoutBuffer(S.i) 
else  TimeoutBuffer(S.i), 

Medium(S  apr  Receive Ack(i).j)  =  = 
if  PreCond(S,ReceiveAck(i))  then 
if  i  =  i 

then  if  StateOf(S.i)  =  Closed  or  StateOf(S.i)  =  Listen 

or  ((StateOf(S.i)  =  SynSent)  and  -IncomingAck #  Valid(S.i)) 
then  Medium(S.i) 

Add  pkt(AckNumber(Front{Medium(S,OppositeSide(i)))), 

Inc  #  Ack{Front(Medium(S,OppositeSide(i)))). 

AnyNat.AnyNat, 

rst) 

else  if  StateOf(S.i)  =  SynReceived 

then  if  -IncomingSeq  #  Valid(S.i) 
then  Medium(S.i) 

Add  pkt(Seq  #  ToSend(S.i), 

Incarnation  #  Out(S.i), 

Seq  #  ToReceive(S.i), 

Incarnation  #  In(S.i). 
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ack) 

else  if  -Incoming Ack#  Valid(S.i)  then 
Medium(S.i) 

Add  pkt(AckNumber(Front(Medium(S,OppositeSide(i)))), 
Inc  tt  Ack(Front(Medium(S,OppositeSide(i)))). 
AnyNat.AnyNat, 
rst) 

else  Medium(S.i) 
else  Medium(S.i) 
else  if  j  =  OppositeSide(i) 

then  Remove(Medium(S,i)) 
else  Medium(S.j) 
else  Medium(Sj); 


y 

ft 


axioms  {ReceiveSyn} 

Incarnation #Out(S  apr  ReceiveSyn(i).j)  =  = 
if  i  =  i  and  PreCond(S,ReceiveSyn(i))  then 
if  StateOf(S.i)  =  Listen 

then  Maxval(Mediom(S,Left)  Append  MedtumfS, Right)) 
else  Incarnation  tt  Out(S.i) 
else  Incarnation #Out(S,j), 

Incarnation  #ln(S  apr  ReceiveSyn(i).j)  =  = 
if  i  =  j  and  PreCond(S.ReceiveSyn(i))  then 
if  ((StateOf(S.i)  =  Listen)  or  StateOf(S.i)  =  SynSent) 
then  inc  #Seq(Front(Medium(S,OppositeSide(i)))) 
else  Incarnation  tt  In(S.i) 
else  Incarnation  #ln(S,j), 

OldUnack(S  apr  ReceiveSyn(i).j)  =  = 
if  i  =  j  and  PreCond(S,ReceiveSyn(i))  then 
if  StateOf(S.i)  =  Listen 
then  ISS(i) 
else  OidUnack(S.i) 
else  OldUnack(SJ). 

Seq  #ToSend(S  apr  ReceiveSyn(i).j)  =  = 
if  i  s  j  and  PreCond(S.ReceiveSyn{il)  then 
if  StateOf(S.i)  =  Listen 
then  1  +  ISS(i) 
else  Seq  #ToSend(S,i) 
else  Seq  #ToSend(S,j), 

Seq  #ToReceive(S  apr  ReceiveSyn(i).j)  =  = 
if  i  =  j  and  PreCond(S.ReceiveSyn(i)) 
then  H  StateOf(S.i)  =  Listen  or  StateOf(S.i)  =  SynSent 

then  1  +  SeqNumber(Front(Medium(S,OppositeSide(i)))) 
else  Seq  tt  ToReceive(S.i) 
else  Seq  #  ToReceive(S.j), 

StateOf(S  apr  ReceiveSyn(i).j)  =  = 
if  i  =  j  and  PreCond{S.ReceiveSyn{i)) 
then  if  StateOf(S.i)  =  Listen 
then  SynReceived 
else  if  StateOf(S.i)  =  SynSent 
then  if  OtdUnack(S.i)  =  ISS(i) 
then  SynReceived 
else  Established 
else  StateOf(S.i) 
else  StateOf(S.j), 

TimeoutBuffer(SaprReceiveSyn(i),i)  =  * 

H  i  =  j  and  PreCond(S.ReceiveSyn(i)) 
then  H  StateOf(S.i)  =  Listen 
then  NewOueueOfPackets 

Add  pkt(lSS(i).Maxval(Medium(S,Left)  Append  Medium(S.Right)), 
1  ♦  SeqNumber(Front(Medium(S,OppositeSide(i)))) 

.Inc  tt  Seq(Front(Medium(S.OppositeSide(i)))). 
synack) 
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else  if  StateOf(S.i)  =  Closed 
then  NewOueueOf  Packets 
else  TimeoutBuffer(S,i) 
else  TimeoutBuffer(S,j), 

Medium(S  apr  ReceiveSyn(i).j)  =  = 
if  PreCond(S,ReceiveSyn(i))  then 
if  i  =  i 

then  if  StateOf(S.i)  =  SynSent 
then  Medium(S.i) 

Add  pkt(Seq  #  ToSend(S.i).lncarnation  * Out(S.i). 

1  +  SeqNumber(Front(Medium(S.OppositeSide(i)))) 

,lnc  tt  Seq(Front(Medium(S,OppositeSide(i)))), 
ack) 

else  if  StateOf(S.i)  =  SynReceived  or  StateOf(S.i)  =  Established 
then  if  IncommgSeq  tt  Valid(S.i) 
then  Medium(S.i) 
else  Medium(S.i) 

Add  pkt(Seq  #  ToSend(S.i), Incarnation  #Out(S,i), 

Seq  tt  T  oReceive(S.i). Incarnation  tt  in(S.i), 
ack) 

else  if  StateOf(S.i)  =  Listen 
then  Medium(S.i) 

Add  pkt(ISS(i),Maxval(Medium(S.Left)  Append 
Med  ium(S,  Right)), 

1  ♦  SeqNumber(Front(Medium(S,OppositeSide(i)))) 
.Inc  it  Seq(Front(Medium(S,OppositeSide(i)))). 
synack) 

else  Medium(S.i) 

Add  pkt(O.Maxval{Medium(S,Left)  Append 
Medium(S.Right)) , 

1  +  SeqNumber(Front(Medium(S,OppositeSide(i)))). 
Inc  tt  Seq(Front(Medium(S,OppositeSide(i)))), 
rst) 

else  it  j  =  OppositeSide(i) 

then  Remove(Medium<S,j)) 
else  Medium(S.j) 
else  Medium(S.i); 

axioms  {ReceiweSynAck} 

Incarnation  #Out(S  apr  ReceiveSynAck(i).j)  =  =  Incarnation  tt  Out(S.j), 

Incarnation  iTInfS  apr  ReceiveSynAck(i),/)  =  = 
if  i  =  j  and  PreCond{S.ReceiveSynAck(i))  then 
if  (StateOf(S.i)  *  SynSent)  and  IncomingAck  tt  Valid(S.i) 
then  Inc  tt  Seq(Front(Medium(S,OppositeSide(i)))) 
else  Incarnation  tt  In(S.i) 
else  Incarnation  tt  ln(S,j). 

Seq  tt  ToSendfS  apr  ReceiveSynAck(i).j)  =  *  Seq  tt  T oSend(S,j), 

OldUnack(S  apr  ReceiveSynAck(i)j)  «  * 
if  i  =  j  and  PreCond(S,ReceiveSynAck(i)) 
then  if  StateOf(S.i)  =  SynSent 
then  It  IncomingAck  #Valid(S,i) 
then  1  +  OldUnack(S.i) 
else  OUUnack(S.i) 

else  if  StateOf(S.i)  =  SynReceived  or  StateOf(S.i)  *  Established 
then  if  IncomingAck  tt  Valid(S.i)  and  IncomingSeq  tt  Valid(S.i) 
then  1  +  OldUnack(S.i) 
else  OfdUnack(S.i) 
else  OldUnack(S.i) 
else  OldUnack(S.i), 

Seq<fToReceive(S  aprReceiveSynAck(i).j)  *  = 

» i « j  and  PreCond(S,ReceiveSyn  Ack(i)) 
then  it  StateOf(S.i)  =  SynSent 
then  if  IncomingAck  #Valid(S, I) 

then  1  +  SeqNumber(Front(Medium(S,OppositeSide(i)))) 
else  Seq  A  ToReceive(S.i) 
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else  Seq  tt  ToReceive(S.i) 
else  Seq  tt  ToReceive(S.j). 

StateOt  (S  apr  ReceiveSynAck(i).j)  =  = 
if  i  =  j  and  PreCond{S,ReceiveSynAck(i)) 
then  if  StateOf(S.i)  =  SynSent  and  Incoming Ack  Valid(S.i) 
then  Established 
else  StateOf(S.i) 
else  StateOf(S.i), 

TimeoutBuffer(S  apr  ReceiveSynAck(i).j)  =  = 
if  i  =  i  and  PreCond(S,ReceiveSynAck(i)) 
then  if  StateOf(S.i)  =  Closed  or  StateOf(S.i)  =  Listen 
then  NewQueueOfPackets 
else  if  StateOf(S.i)  =  SynSent 

then  N  IncommgAck  tt  Valid(S.i) 

then  DeletePacket(TimeoutBuffer(S,i).OIdUnack(S,i)) 
else  NewQueueOfPackets 
else  TimeoutBuffer(S,i) 
else  TimeoutBuffer(S.j). 

Medium(S  apr  ReceiveSynAck(i).j)  =  = 
if  PreCond(S.ReceiveSynAck(i))  then 
if  i  =  j 

then  if  StateOf(S.i)  =  Closed  or  StateOf(S.i)  =  Listen 
then  Medium(S.i) 

Add  pkt(AckNumber(Front(Medium(S.OppositeSide(i)))), 

Inc  tt  Ack(Front(Medium(S.OppositeSide(i)))), 

AnyNat.AnyNat. 

rst) 

else  if  Stated(S.i)  =  SynSent 

then  if  IncommgAck#  Valid(S.i) 
then  fsledium(S.i) 

Add  pkt(Seq  tt  ToSend(S.i), Incarnation  tt  Out(S.i), 

1  +  SeqNumber(Front(Medium(S.OppositeSide(i)))) 

,lnc  tt  Seq(Front(Medium(S.OppositeSide(i)))). 
ack) 

else  Medium(S.i) 

Add  pkt(AckNumber(Front(Medium(S.OppositeSide(i)))). 

Inc  tt  Ack(Front(Medium(S.OppositeSide(i)))). 

AnyNat.AnyNat, 

rst) 

else  if  Stated(S.i)  =  Established 
then  if  IncomingSeq  tt  Valid(S.i) 
then  Medium(S.i) 
else  Medium(S.i) 

Add  pkt(Seq#ToSend(S.i), 

Incarnation  tt  Out(S.i), 

Seq  tt  ToReceive(S.i), 

Incarnation  tt  In(S.i), 
ack) 

else  if  StateOf(S.i)  =  SynReceived 
then  if  -IncomingSeq  #Valtd(S.i) 
then  Medium(S.i) 

Add  pkt<Seq  tt  ToSend(S.i), 

Incarnation  tt  Out(S.i). 

Seq#ToReceive(S,i), 

Incarnation  #ln(S.i). 
ack) 

else  if  -IncomingAck#  Valid(S.i)  then 
Medium(S.i) 

Add  pkt(AckNumber(Front(Medium(S,OppositeSide(i)))). 
Inc  tt  Ack(Front(Medium(S.OppositeSide(i)))), 
AnyNat.AnyNat, 
rst) 

else  Medium(S.i) 
else  Medium(S.i) 
else  if  j  *  OppositeSide(i) 
then  Remove(Medium(S,j)) 
else  Medium(S.i) 
else  Medium(S.j); 
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axioms  {Timeout} 

Incarnation  it  Out(S  apr  Timeout(i)j)  *  =  Incarnation  #Out(S,j), 

Incarnation  tt  ln(S  apr  Timeout(i).j)  =  =  Incarnation  tt  ln(S,j), 

OldUnackfS  apr  Timeout(i).j)  =  =  OldUnack(SJ), 

Seq#ToSend(S  apr  Timeout(i).j)  =  =  Seq  #ToSend(S,j), 

Seq#ToReceive(S  apr  Timeout(i),j)  =  =  Seq  #  ToReceive(S.i). 

StateO*(S  apr  Timeout(i).j)  =  =  StateOf(SJ), 

Medium(S  apr  Timeout(i).j)  =  = 
if  i  =  j  and  PreCond(S,Timeout(i)) 
then  Append(Medium(S,i),TimeoutBuffer(S,i)) 
else  Medium(S.j), 

TimeoutBuffer(S  apr  Timeout(i),j)  =  =  TimeoutBuffer(S.j); 
axioms  (LoseMessage) 

Incarnation  #Out(S  apr  LoseMessage(i).j)  =  =  Incarnation  U  Out(S.j), 

Incarnation  #ln(S  apr  LoseMessage(i)J)  =  =  Incarnation  #ln(S,j), 

OldUnack(S  apr  LoseMessage(i)j)  =  =  OldUnack(S.j), 

Seq#ToSend(S  apr  LoseMessage(i).j)  =  =  Seq  #  ToSend(Sj), 

Seq#ToReceive(SaprLoseMessage(i),j)  =  =  Seq  it  ToReceive(S.j), 

StateOffS  apr  LoseMessage(i),j)  =  =  StateOf(S.j), 

MediumfS  apr  LoseMessage(i).j)  =  = 
if  i  =  j  and  PreCond(S,LoseMessage(i)) 
then  Remove(Medium(S,i)) 
else  Medium(S.j). 

TimeoutBuffer(S  apr  LoseMessage(i).j)  =  =  TimeoutBuffer(S.j); 


11.2  Auxiliary  Data  Type  Definitions 

type  Packet; 

needs  types  Integer,  ControlField; 

declare  dummy,  pk:  Packet; 

declare  seq  it ,  ack  it .  inc  it  s,  inc  it  a:  Integer; 

declare  cf:  ControlField; 

interface  pkt(seq  it ,  inc  it  s,  ack  # ,  inc  9  a.  cf):  Packet; 

interfaces SeqNumber(pk),  AckNumber(pk),  Inc S'Seq(pk),  Inc#  Ack(pk):  Integer; 
interface  Control(pk):  ControlField; 
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axiom 

) 


dummy  =  pk 

=  =  (  (SeqNumber(dummy)  =  SeqNumber(pk))  and  AckNumberfdummy 

s  AckNumber(pk) 
and  Control(dummy)  =  Control(pk) 
and  Inc  8  Ack(dummy)  a  Inc  8  Ack(pk) 
and  Inc  8  Seq(dummy)  =  Inc#  Seq(pk)); 


axiom  SeqNumber(pkt(seq  8 ,  inc  8  s,  ack  8 ,  inc  8  a,  cf ))  =  =  seq  8 ; 

axiom  AckNumber{pkt(seq  8 .  inc  8  s,  ack  8 ,  inc  8  a,  cf))  =  =  ack  8 ; 

axiom  Inc  8  Seq(pkt(seq  8  ,  inc  8  s.  ack  8  ,  inc  8  a,  cf ))  =  =  inc  8  s; 

axiom  Inc  8  Ack(pkt(seq  8 ,  inc  8  s,  ack  8 ,  inc  8  a.  cf ))  =  -  inc  8  a, 


axiom  Control(pkt(seq  8 ,  inc  8  a,  ack  8 ,  inc  8  a.  cf))  =  =  cf ; 

end  {Packet}  ; 
type  QueueOfPacket; 


needs  type  Packet 

declare  dummy,  q,  qi,  q2,  qq  QueueOfPacket; 
declare  i,  it .  i2.  ii:  Packet; 


interfaces 

NewQueueOfPacket.  q  Add  i,  Remove(q). 
Appendfql,  q2).  que(i);  QueueOfPacket; 

infix  Add; 


interfaces 

Front(q),  Back(q):  Packet; 
interfaces 

NormalForm(q),  Induction(q),  i  in  q:  Boolean, 
•nfix  in; 


axioms  dummy  =  dummy  =  =  TRUE, 

q  Add  i  =  NewQueueOfPacket  =  =  FALSE. 
NewQueueOfPacket  =  q  Add  i  =  =  FALSE, 
qi  Add  ii  =  q2  Add  i2  =  =  ((qi  =  q2)  and  (ii  =  i2)), 

Remove(NewQueueOfPacket)  =  =  NewQueueOfPacket, 
Removefq  Add  i)  =  =  if  q  =  NewQueueOfPacket 
thenq 

else  Remove(q)  Add  i, 

Appendfq.  NewQueueOfPacket)  =  =  q, 

Appendjq,  qi  Add  ii)  =  =  Append(q,  qi)  Add  ii, 

que(i)  =  =  NewQueueOfPacket  Add  i, 

Frontfq  Add  i)  =  =  if  q  =  NewQueueOfPacket 
then  i 

else  Front(q), 

Back(q  Add  i)  =  =  i, 

i  in  NewQueueOfPacket  =  *  FALSE, 
i  in  (q  Add  ii)  x  =  (i  in  q  or  (i  =  ii)); 

rulelemma 

AppendfNewQueueOfPacket,  q)  =  *  q; 

schemas  NormalForm(q)  =  =  cases(Prop(NewQueueOfPacket), 
all  qq.  ii  (Prop<qq  Add  ii))), 
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